From the vantage point of most users, an application's interaction with a device is simple. For example, when a user of a word processing program wants to print a document, the user simply presses a button (or interacts with a dialog) then picks up the printed sheet of paper at the printer. However, behind the scenes at the software and hardware levels, this process may involve a complex integration of several system services resulting in the printed sheet waiting in the printer tray. This complexity creates, in many cases, a close binding that may inhibit flexibility in the interaction between applications and devices.
Devices are typically represented to a computing device via a device driver. A device driver is a strongly typed component which enables applications and/or system services to interact directly with a device that is associated with the driver. A typical device driver is primarily responsible for enabling communication between the host computing device and the device to which it is attached. This communication may be via a direct link on the circuit board associated with a specific pin on the central processing unit (CPU), via a generalized expansion bus such as Peripheral Component Interconnect (PCI), Inter-Integrated Circuit (I2C), or Universal Serial Bus (USB), or via a network medium such as Ethernet. Communication over this link involves both command and control as well as data exchange. The device driver provides either a normalized (e.g., system defined) view of a particular device, such that the driver represents a class of devices, or a specialized implementation for the particular device in question.
For example, traditional printing from an application may proceed as depicted in FIG. 1. As shown, process 100 begins at block 102 with a user indicating to an application (e.g. a word processing application, image editor, spreadsheet program, and the like) that a document is to be printed at a particular printing device. At block 104, the application loads the particular device context for the requested printer. The device context is often a system provided abstraction of the actual device and enables interaction between the application, system services, and the printer device driver for the purpose of creating printed output. Based on information provided in the device context, the application determines one or more settings and/or options available for printing to the particular printing device. At block 106, the application creates a formalized description of a fixed page layout for each page of the document to be printed, based on the settings and/or options specified by the user. In some cases, instead of creating a fixed page layout, each page is drawn on (e.g., as in many ink jet printers). At block 108, the application submits the formalized description for each page via the device context, which results in either spooling the formalized page description(s) directly to the printer or submitting them via a print server. In this example, the application creates the print layout and then interacts directly with the device via the device context to directly negotiate a format for the output. The device context then passes the output to a printing subsystem which then prints. Thus, the application interacts more or less directly with the printer or other type of device, creating a close binding between application and device.